Apparatus and methods for content transfer protection

ABSTRACT

Methods and apparatus for ensuring protection of transferred content. In one embodiment, content is transferred while enabling a network operator (e.g., MSO) to control and change rights and restrictions at any time, and irrespective of subsequent transfers. This is accomplished in one implementation by providing a premises device configured to receive content in a first encryption format and encodes using a first codec, with an ability to transcrypt and/or transcode the content into an encryption format and encoding format compatible with a device which requests the content therefrom (e.g., from PowerKey/MPEG-2 content to DRM/MPEG-4 content). The premises device uses the same content key to encrypt the content as is used by the requesting device to decrypt the content.

RELATED APPLICATIONS

The present application is related to commonly owned U.S. PatentApplication Ser. No. 11/584,208 filed on Oct. 20, 2006 and entitled“Downloadable Security and Protection Methods and Apparatus”, now issuedas U.S. Pat. No. 8,520,850, commonly owned U.S. patent application Ser.No. 11/657,828 filed on Jan. 24, 2007 and entitled “Apparatus andMethods for Provisioning in a Download-Enabled System”, now issued asU.S. Pat. No. 8,621,540, commonly owned U.S. patent application Ser. No.12/480,597 filed Jun. 8, 2009 and entitled “Media Bridge Apparatus andMethods”, now published as U.S. Patent Application Publication No.2010/0313225, and commonly owned U.S. patent application Ser. No.12/834,801 filed on Jan. 12, 2010 and entitled “Apparatus and Methodsfor Content Management and Account Linking Across Multiple ContentDelivery Networks”, now published as U.S. Patent Application PublicationNo. 2012/0008786, each of the foregoing being incorporated herein byreference in its entirety.

COPYRIGHT

A portion of the disclosure of this patent document contains materialthat is subject to copyright protection. The copyright owner has noobjection to the facsimile reproduction by anyone of the patent documentor the patent disclosure, as it appears in the Patent and TrademarkOffice patent files or records, but otherwise reserves all copyrightrights whatsoever.

BACKGROUND

1. Technology Field

The disclosure relates generally to the field of data and contentdistribution and delivery via a content distribution or other network.In one exemplary aspect, the disclosure relates to the delivery ortransfer of content in a protected manner.

2. Description of Related Technology

A wide range of services and functions including e.g., digitalprogramming (movies, etc.), digital video-on-demand (VOD), personalvideo recorder (PVR), Internet Protocol television (IPTV), digital mediaplayback and recording, as well high-speed Internet access and IP-basedtelephony (e.g., VoIP), etc. are available for delivery to consumers attheir premises for reasonable prices or subscription fees. Otherservices available to network users include access to and recording ofdigital music (e.g., MP3 files), as well local area networking(including wire-line and wireless local area networks or WLANs) fordistributing these services throughout the user's premises, and beyond.

The foregoing services and functions may be provided to the user via awide variety of different equipment environments including, inter alia,cable modems, Wi-Fi hubs, WMANs (such as e.g., WiMAX networks), Ethernethubs, gateways, switches and routers, computers, servers, cable set-topboxes, public switched telephone networks (PSTNs), cellulartelephones/smartphones (including e.g., LTE-enabled networks), tabletcomputers (including so-called “phablets”), and portable digital musicdevices. Additionally, the foregoing may be provided by one or morevendors or service providers including e.g., a cable service provider(e.g., MSO), cellular service provider (CSP), wireless service provider(WSP), VoIP service provider, music download service, Internet serviceprovider (ISP), PSTN telephone service, etc., and/or content may bedistributed between devices in any of the foregoing networks.

As the number of devices and providers increases, there is an increasedneed to provide integration across multiple delivery platforms andnetworks. Specifically, movement of content delivered by these serviceswithin the user's premises (and/or outside the premises, such as betweennetworks) is often substantially frustrated, largely due to concernsrelating to protection of valuable (e.g., copyrighted) content, andsurreptitious reproduction and distribution thereof. Such unauthorizedreproduction and distribution not only detracts from the networkoperator's revenue and commercial viability, but also that of thecontent source (e.g., movie studio, recording studio/artist, etc.).

Various methods have heretofore been employed by network operators inorder to attempt to frustrate surreptitious access to, and copying anddistribution of, valuable content. For example, conditional access (CA)technologies have been utilized for such purposes. Additionally,symmetric or asymmetric encryption technologies, such as those inaccordance with the Data Encryption Standard (DES) technique or AdvancedEncryption Standard (AES) may be used to secure content delivery.So-called “trusted domains” and digital rights management (DRM)solutions have also been utilized for this purpose. Each of thesetechniques is now described in greater detail.

Conditional Access

Conditional access (CA) technologies are typically incorporated intocontent-based networks, such technologies including the digital encodingof various types of data including audio and video programming andmusic. Conditional access can generally be defined as the control ofwhen and how a user may view and use the associated programming orinformation. Different types of conditional access may be desirable in anetwork delivery system in order to, e.g., accommodate improvements inthe technology over time, as well as different conditional accessattributes such as security and category of programming or user accesslevel.

A variety of traditional methods of conditional access exist including,e.g., “PowerKey”, NDS, and DigiCipher. A generalized conditional accessmodel is also provided by the well-known DVB (Digital VideoBroadcasting) Specification TS 101 197 V1.2.1 (02/02), DVB SimulCrypt;Part 1: “Head-end architecture and synchronization”, and TS 103 197V1.2.1 (02/02): “Head-end Implementation of SimulCrypt”, eachincorporated herein by reference in its entirety.

FIG. 1a illustrates an exemplary prior art architecture 200 forproviding content to a plurality of consumer premises equipment (CPE)via e.g., an HFC network using a conditional access scheme.Specifically, the network 100 distributes PowerKey protected content tothe CPE. In order to access the content, each CPE utilizes the so-called“CableCard” plug-in security module access technology (also known as “apoint-of-deployment (POD) module”). See, e.g., the CableCard-Hostinterface specification, which defines the interface between a digitalcable receiver or STB (Host device) and the CableCard device provided bythe MSO/cable operator. CableCard was developed to satisfy certainsecurity requirements, and to allow retail availability of host devices,e.g., set-top boxes, digital cable ready televisions, DVRs, personalcomputers (PCs), integrated digital televisions, etc., for receivingcable services. The CableCard, comprising a PCMCIA device, can beinserted into a host device, allowing a viewer to receive cable systems'secure digital video services, e.g., pay-per-view (PPV) TV, electronicprogram guides, premium subscription channels, etc.

Specifically, the CableCard contains conditional access functionality,as well as the capability of converting messages to a common format.Thus, the CableCard provides a cable operator with a secure device atthe subscriber premises, and acts as a translator so that the hostdevice needs to understand a single protocol, regardless of the type ofthe network to which it is connected.

In FIG. 1a , the same PowerKey protected content (Content A) maytherefore be sent to multiple CPE. Each CPE can then use its CableCardto access the content.

However, the requirement for a CableCard is comparatively tedious andexpensive, especially given the recent trend toward home networkingtechniques which enable content transfer to and use on all of a user'sdevices (including personal computers, laptop and notebook computers,tablets, smartphones, etc.).

Moreover, the prior art PowerKey approach described above has noauthentication entity or “proxy” that can authenticate CPE or otherconnected devices in anticipation of providing download services, novideo (media) provisioning system, and hence by nature is highlylocalized.

“Trusted Domains”

Another related approach for content protection comprises the creationand enforcement of a “trusted domain” or TD. Specifically, such atrusted domain (TD) comprises an area (physically or virtually) withinwhich programming or other content is protected from unauthorizedaccess, distribution and copying. For example, in a cable network, atrusted domain may include not only the network portion whereprogramming content traditionally is secured by, and within totalcontrol of, a cable operator (including, e.g., the headend, HFC deliverynetwork, etc.,) but also user devices or CPE at subscribers' premiseswhich are capable of receiving and securely storing programming content.

Using the trusted domain approach, the network operator can guaranteecertain subscriber access, distribution, and usage policy enforcementwith respect to content held within the domain. For example, a digitalrepresentation of a movie held within an operator's TD (e.g., on a harddrive of a user device) cannot be distributed over the Internet,wireless network, etc. in viewable form, and cannot become a source forduplication of multiple viewable copies.

Accordingly, a home network on which content may be transferred may becreated; however, additional mechanisms are needed to ensure protectionof the content within the trusted domain. One exemplary approach ofimplementing a trusted domain, described in co-owned U.S. PatentApplication Publication No. 2006/0047957 filed Dec. 7, 2004 and entitled“Technique For Securely Communicating Programming Content”, now issuedas U.S. Pat. No. 8,312,267, which is incorporated herein by reference inits entirety, comprises using two cryptographic elements (e.g.,encryption keys), associated with a user and his/her client device(s),respectively, that control access to content stored in the clientdevice(s) within the domain. For example, the content stored in theclient device may be encrypted using a private or secret key inaccordance with the Data Encryption Standard (DES) or AdvancedEncryption Standard (AES) algorithms. When the encrypted content istransported from the client device to another device within the domainassociated with the same user (or other common parameter or feature),the second device needs the cryptographic element (e.g., the secret key)to decrypt the encrypted content. To that end, the second device alsoreceives from the source device an encrypted version of this secret key.The latter is generated by encrypting the secret key using a second anddistinct cryptographic element (e.g., a public key in accordance with apublic key algorithm) associated with the subscriber. The second deviceprovides the encrypted version of the secret key to a remote apparatus,e.g., in a headend, where the secret key is recovered based on at leastthe encrypted version of the secret key and data relating to that useror client device. The second device then receives from the head-endanother encrypted version of the secret key, which is generated byencrypting the recovered secret key using a third cryptographic element(e.g., a public key in accordance with a public key algorithm)associated with the second device. Based on at least this secondencrypted version of the secret key, the secret key can be recovered inthe second device to decrypt the encrypted content.

However, generally speaking, any “trusted domains” that might beestablished are not extendable beyond the CPE on the client side of thedelivery network.

Digital Rights Management (DRM)

Another approach used to control the distribution and use of protectedcontent within a content-based network is to employ so-called digitalrights management (DRM). For example, Media rights management systemssuch as the Microsoft Windows® Media Digital Rights Manager (DRM), maybe used.

FIG. 1b illustrates an exemplary prior art network for transfer ofcontent using DRM techniques. As shown, the network generally comprisesa content server in communication with a plurality of client devices(CPE 1, CPE 2, etc.) via a hybrid fiber-coaxial (HFC) network.

First content, Content A-1 is provided to a first CPE (CPE 1), uponrequest therefor. The digital media or content is encrypted and lockedwith a “license key” that is particular to the requesting device (DRMLicense 1). The license key is stored in a license file or other datastructure which is distributed separately from the media or content tothe requesting device. A user can obtain the encrypted media file from acontent server (such as by, e.g., receiving it in a broadcast,downloading it from a web site, purchasing it on a physical media,etc.). To play the digital media file, the user must acquire the licensefile including the license key for that media file from a DRM server.The user acquires the license key by accessing a pre-delivered license(which includes license terms or policies). Alternatively, when the userplays the file for the first time, a procedure is invoked for retrievingthe license via a network connection or other delivery mode (e.g., theInternet). After obtaining the license with the license key, the user isable to access the media file according to the rules or rights specifiedin the license policies.

It is noted that, in FIG. 1b , the system operator (e.g., MSO) providesa means for encrypting the requested content with the device-specificlicense key to create the secured content file (Content A-1). Therequesting CPE (CPE 1) will require the DRM license (DRM License 1) toaccess the content in the file as discussed above. In order to ensurethat the requesting device and/or user is entitled to access thecontent, an association or data record is generated and maintained at adatabase at the network headend. Upon request for the DRM license, theDRM server determines whether the user/device is entitled to accessprior to providing the DRM license thereto.

The DRM license includes rights of the devices and/or users, the rightsdetermine aspects of the playback, copying, transfer, etc. of thecontent. The content source may set the usage rules and policies forlicensing the content. When the user/device requests the DRM licensefrom the DRM server, such as via a trusted software client, the rightsparticular to that user are utilized. The trusted client retrieves thecontent file and the content key, which it uses to then access thecontent.

As illustrated in FIG. 1b , when a second CPE (CPE 2) requests the samecontent (Content A), the content server provides content encrypted witha content key specific to the second device thereby creating a ContentA-2 version of the requested content. Likewise, the DRM server willprovide CPE 2 with DRM License 2 for accessing the protected content.

However, as previously noted, existing DRM technologies utilizedevice-specific encryption/decryption keys. Such DRM-based systems areaccordingly incompatible with the previously referenced home networkingmodels, as the transfer thereon would result in either (i) content thatis not usable at the receiving device (due to failure to possess theappropriate license key or file), or (ii) simply a transfer of thecontent in an unprotected form.

Moreover, similar to CA technologies, the DRM approach described abovehas no authentication entity or “proxy” that can authenticate CPE orother connected devices in anticipation of providing download services,no video (media) provisioning system, and hence by nature is highlylocalized.

Various other technologies have demonstrated an ability to transfercontent within a home network; however, such systems either do not useany DRM content protection, or utilize in-home DRM license generationfor content protection. For example, the Motorola Televation™ devicereceives PowerKey signaling, and securely translates the rights andrestrictions of that content from the PowerKey signaling to an InternetProtocol Rights Management-Home Network (IPRM-HN)/SecureMedia in-homeDRM license. However, as discussed herein, in-home DRM licensegeneration requires sharing sensitive information with the in-homedevice. Therefore, this mechanism dilutes the security of the DRMsystem, and may threaten the protection of the content.

Accordingly, improved apparatus and methods for distributing digitalservices to (and within) a user's premises are needed. Such improvedapparatus and methods would ideally provide protection of content withinthe user's premises network, as well as outside of the premises networkand across other networks.

In addition, the improved apparatus and methods would ideally enablecontent transfer within a given premises network in accordance with therights established for the specific content, user, and/or rendering orstorage device, without diluting or otherwise compromising the securityof the transferred content.

SUMMARY

The foregoing needs are addressed herein by providing, inter alia,methods and apparatus for content transfer protection.

In a first aspect, a premises gateway apparatus configured to providecontent to one or more client devices in communication therewith isdisclosed. In one embodiment, said gateway apparatus includes: at leastone first interface configured to permit communication between thegateway apparatus and a first network at least one second interfaceconfigured to communicate with said one or more client devices; astorage apparatus; and a digital processor configured to run at leastone computer program thereon. In one variant, said computer programcomprises a plurality of instructions which are configured to, whenexecuted by said digital processor: request and receive said content anda content key from said first network via said first interface; receivea request from at least one of said one or more client devices for saidcontent; decrypt said content via said content key; transcode saidcontent from a first encoding format to a second encoding format, saidsecond encoding format being compatible with capabilities of said atleast one of said one or more client devices; re-encrypt said contentvia said content key; and provide said content to said at least one ofsaid one or more client devices via said second interface.

In a second aspect, a method of providing content to one or more clientdevices is disclosed. In one embodiment, the one or more client devicesare operative in a premises network sub-portion of a content deliverynetwork, and said method includes: receiving said content at anintermediary entity of said premises network from a content server ofsaid content delivery network, said content being encrypted according toa first access control standard; receiving a rights package from saidcontent delivery network; receiving a request for said content from atleast one of said one or more client devices in said premises network;and substantially in response to said request, said intermediary entity:decrypting said content via at least information received in said rightspackage; transcoding said content from a first encoding format to asecond encoding format; re-encrypting said content according to a secondaccess control standard; and providing said content to said at least oneof said one or more client devices.

In a third aspect, a digital video recorder (DVR) apparatus configuredto enable synchronization of content to one or more portable mediadevices (PMDs) is disclosed. In one embodiment, said DVR includes: atleast one first interface configured to communicate with one or moreentities of a content delivery network; a second interface configured tocommunicate with said one or more PMDs; a storage entity configured tostore a plurality of encrypted content received from a content server ofsaid content delivery network; and a processor configured to: run atleast a digital rights management (DRM) client application thereon, saidDRM client application configured to request and receive a DRM licensefrom said content delivery network; and run at least one second computerapplication. In one variant, said computer program comprises a pluralityof instructions which are configured to, when executed: receive arequest for first content from said one or more PMD; identify said firstcontent among said plurality of encrypted content stored at said storageentity; decrypt said first content via at least information contained insaid DRM license; determine whether said identified first contentcomprises a format compatible with said one or more PMD; when it isdetermined that said format is not compatible, transcode said firstcontent to a format compatible with said one or more PMD; re-encryptsaid first content according to DRM standards; and provide said contentto said one or more PMD.

In a fourth aspect, a method of synchronizing content from a firstpremises device to at least one portable device in communicationtherewith is disclosed. In one embodiment, said method includes: storingat least first content at a storage entity of said first in-home device,said at least first content being stored in a first encrypted format;requesting and storing a license via a client application running onsaid first premises device, said license received from a server indirect or indirect communication with said first premises device;receiving a request at said first premises device for said first contentstored at said storage entity from said portable device; using at leastinformation contained in said license to decrypt said first content fromsaid first encrypted format and re-encrypt said first content to asecond encrypted format; transcoding said first content from a firstencoding format not compatible with said portable device to a secondencoding format compatible with said portable device; and synchronizingsaid transcoded and re-encrypted first content to said portable device.

In a fifth aspect, a computer readable apparatus is disclosed. In oneembodiment, the computer readable apparatus is configured to run atleast one computer program thereon, the computer program comprising aplurality of instructions which are configured to, when executed,provide content to one or more client devices.

In a sixth aspect, a system is disclosed. In one embodiment, the systemcomprises a network for providing content to a gateway device, thegateway device configured to process the content and provide the same toone or more client devices in communication therewith.

In a seventh aspect, a client device is disclosed. In one embodiment,the client device is configured to receive content synchronized from agateway apparatus.

Other features and advantages of the present disclosure will immediatelybe recognized by persons of ordinary skill in the art with reference tothe attached drawings and detailed description of exemplary embodimentsas given below.

BRIEF DESCRIPTION OF THE DRAWINGS

FIGS. 1a and 1b are a block diagrams illustrating typical prior artimplementations of network architectures for providing protected contentto a plurality of client devices in a network.

FIG. 2 is a functional block diagram illustrating an exemplary HFC cablenetwork configuration useful with the present disclosure.

FIG. 2a is a functional block diagram illustrating one exemplary HFCcable network headend configuration useful with the present disclosure.

FIG. 2b is a functional block diagram illustrating one exemplary localservice node configuration useful with the present disclosure.

FIG. 2c is a functional block diagram illustrating one exemplarybroadcast switched architecture (BSA) network useful with the presentdisclosure.

FIG. 2d is a functional block diagram illustrating one exemplarypacketized content delivery network architecture useful with the presentdisclosure.

FIGS. 3a and 3b are block diagrams illustrating exemplary embodiments ofnetwork architecture s for transferring protected content according tothe present disclosure.

FIGS. 4a and 4b are logical flow diagrams illustrating exemplaryembodiments of methods for transferring protected content according tothe present disclosure.

FIG. 5a is a functional block diagram illustrating an exemplaryembodiment of a gateway apparatus and of a consumer premises apparatus(CPE) for the transfer of protected content according to the disclosure.

FIG. 5b is a functional block diagram illustrating an exemplaryembodiment of a digital video recorder (DVR) apparatus and of a portablemedia device (PMD) for the transfer of protected content according tothe disclosure.

DETAILED DESCRIPTION

Reference is now made to the drawings, wherein like numerals refer tolike parts throughout.

As used herein, the term “application” refers generally and withoutlimitation to a unit of executable software that implements a certainfunctionality or theme. The themes of applications vary broadly acrossany number of disciplines and functions (such as on-demand contentmanagement, e-commerce transactions, brokerage transactions, homeentertainment, calculator etc.), and one application may have more thanone theme. The unit of executable software generally runs in apredetermined environment; for example, the unit could comprise adownloadable Java Xlet™ that runs within the JavaTV™ environment.

As used herein, the terms “client device” and “end user device” include,but are not limited to, set-top boxes (e.g., DSTBs), gateways, DVRs,modems, personal computers (PCs), and minicomputers, whether desktop,laptop, or otherwise, and mobile devices such as handheld computers,PDAs, personal media devices (PMDs), tablets, and smartphones.

As used herein, the term “codec” refers to a video, audio, or other datacoding and/or decoding algorithm, process or apparatus including,without limitation, those of the MPEG (e.g., MPEG-1, MPEG-2,MPEG-4/H.264, etc.), Real (RealVideo, etc.), AC-3 (audio), DiVX,XViD/ViDX, Windows Media Video (e.g., WMV 7, 8, 9, 10, or 11), ATI Videocodec, or VC-1 (SMPTE standard 421M) families.

As used herein, the term “computer program” or “software” is meant toinclude any sequence or human or machine cognizable steps which performa function. Such program may be rendered in virtually any programminglanguage or environment including, for example, C/C++, Fortran, COBOL,PASCAL, assembly language, markup languages (e.g., HTML, SGML, XML,VoXML), and the like, as well as object-oriented environments such asthe Common Object Request Broker Architecture (CORBA), Java™ (includingJ2ME, Java Beans, etc.), Binary Runtime Environment (e.g., BREW), andthe like.

The terms “Consumer Premises Equipment (CPE)” and “host device” referwithout limitation to any type of electronic equipment located within aconsumer's or user's premises and connected to a network. The term “hostdevice” includes terminal devices that have access to digital televisioncontent via a satellite, cable, or terrestrial network. The host devicefunctionality may be integrated into a digital television (DTV) set. Theterm “consumer premises equipment” (CPE) includes such electronicequipment such as set-top boxes, televisions, Digital Video Recorders(DVR), gateway storage devices (Furnace), and ITV Personal Computers.

As used herein, the term “database” refers generally to one or moretangible or virtual data storage locations, which may or may not bephysically co-located with each other or other system components.

As used herein, the term “display” refers any type of device adapted todisplay information, including without limitation CRTs, LCDs, TFTs,plasma displays, LEDs, incandescent and fluorescent devices. Displaydevices may also include less dynamic devices such as, for example,printers, e-ink devices, and the like.

As used herein, the term “DVR” (digital video recorder) refers generallyto any type or recording mechanism and/or software environment wherebycontent sent over a network can be recorded and selectively recalled.Such DVR may be dedicated in nature, or part of a non-dedicated ormulti-function system.

As used herein, the term “DOCSIS” refers to any of the existing orplanned variants of the Data Over Cable Services InterfaceSpecification, including for example DOCSIS versions 1.0, 1.1, 2.0 and3.0.

As used herein, the term “gateway” includes, without limitation, devicesconfigured to interface with a network, and pass signals to or exchangesignals with, another device in communication therewith. Variousexemplary gateways are described in, inter alia, co-owned U.S. patentapplication Ser. No. 11/818,236 filed on Jun. 13, 2007 entitled“PREMISES GATEWAY APPARATUS AND METHODS FOR USE IN A CONTENT-BASEDNETWORK”, now issued as U.S. Pat. No. 7,954,131, U.S. patent applicationSer. No. 12/582,619 filed on Oct. 20, 2009 and entitled “GATEWAYAPPARATUS AND METHODS FOR DIGITAL CONTENT DELIVERY IN A NETWORK”, nowissued as U.S. Pat. No. 9,027,062, and co-pending U.S. patentapplication Ser. No. 12/480,597 filed on Jun. 8, 2009and entitled “MEDIABRIDGE APPARATUS AND METHODS”, each of the foregoing being incorporatedherein by reference in its entirety.

As used herein, the term “headend” refers generally to a networkedsystem controlled by an operator (e.g., an MSO or multiple systemsoperator) that distributes programming to MSO clientele using clientdevices. Such programming may include literally any informationsource/receiver including, inter alia, free-to-air TV channels, pay TVchannels, interactive TV, and the Internet.

As used herein, the terms “Internet” and “internet” are usedinterchangeably to refer to inter-networks including, withoutlimitation, the Internet.

As used herein, the terms “microprocessor” and “digital processor” aremeant generally to include all types of digital processing devicesincluding, without limitation, digital signal processors (DSPs), reducedinstruction set computers (RISC), general-purpose (CISC) processors,microprocessors, gate arrays (e.g., FPGAs), PLDs, reconfigurablecomputer fabrics (RCFs), array processors, secure microprocessors, andapplication-specific integrated circuits (ASICs). Such digitalprocessors may be contained on a single unitary IC die, or distributedacross multiple components.

As used herein, the terms “MSO” or “multiple systems operator” referwithout limitation to a cable, fiber to the home (FTTH), fiber to thecurb (FTTC), satellite, Hybrid Fiber Copper (HFCu), or terrestrialnetwork provider having infrastructure required to deliver servicesincluding programming and data over those mediums.

As used herein, the terms “network” and “bearer network” refer generallyto any type of telecommunications or data network including, withoutlimitation, hybrid fiber coax (HFC) networks, HFCu networks, satellitenetworks, telco networks, and data networks (including MANs, WANs, LANs,WLANs, internets, and intranets). Such networks or portions thereof mayutilize any one or more different topologies (e.g., ring, bus, star,loop, etc.), transmission media (e.g., wired/RF cable, RF wireless,millimeter wave, optical, etc.) and/or communications or networkingprotocols.

As used herein, the term “interface” refers to any signal, data, orsoftware interface with a component, network or process including,without limitation, those of the FireWire (e.g., FW400, FW800, etc.),USB (e.g., USB2), Ethernet (e.g., 10/100, 10/100/1000 (GigabitEthernet), 10-Gig-E, etc.), MoCA, Coaxsys (e.g., TVnet™), radiofrequency tuner (e.g., in-band or OOB, cable modem, etc.), Wi-Fi(802.11), WiMAX (802.16), PAN (e.g., 802.15), cellular (e.g., 3G,LTE/LTE-A/TD-LTE, GSM, etc.) or IrDA families.

As used herein, the term “node” refers to any functional entityassociated with a network, such as for example an OLT or ONU, whetherphysically discrete or distributed across multiple locations.

As used herein, the term “QAM” refers to modulation schemes used forsending signals over cable networks. Such modulation scheme might useany constellation level (e.g. QPSK, 16-QAM, 64-QAM, 256-QAM, etc.)depending on details of a cable network. A QAM may also refer to aphysical channel modulated according to the schemes.

As used herein, the term “server” refers to any computerized component,system or entity regardless of form which is adapted to provide data,files, applications, content, or other services to one or more otherdevices or entities on a computer system or network.

As used herein, the terms “service”, “content”, and “stream” aresometimes used synonymously to refer to a sequence of packetized datathat is provided in what a subscriber may perceive as a service. A“service” (or “content”, or “stream”) in the former, specialized sensemay correspond to different types of services in the latter,non-technical sense. For example, a “service” in the specialized sensemay correspond to, among others, video broadcast, audio-only broadcast,pay-per-view, or video-on-demand. The perceivable content provided onsuch a “service” may be live, pre-recorded, delimited in time,undelimited in time, or of other descriptions. In some cases, a“service” in the specialized sense may correspond to what a subscriberwould perceive as a “channel” in traditional broadcast television.

As used herein, the term “service group” refers without limitation toeither a group of service users (e.g., subscribers), or the resourcesshared by them in the form of, for example, entire cable RF signal, onlythe RF channels used to receive the service or otherwise treated as asingle logical unit by the network for resource assignment.

As used herein, the term “user interface” refers to, without limitation,any visual, graphical, tactile, audible, sensory, or other means ofproviding information to and/or receiving information from a user orother entity.

As used herein, the term “Wi-Fi” refers to, without limitation, any ofthe variants of IEEE-Std. 802.11 or related standards including802.11a/b/g/n/s/v or 802.11-2012.

As used herein, the term “wireless” means any wireless signal, data,communication, or other interface including without limitationBluetooth, 3G (3GPP/3GPP2), HSDPA/HSUPA, TDMA, CDMA (e.g., IS-95A,WCDMA, etc.), FHSS, DSSS, GSM, PAN/802.15, WiMAX (802.16), 802.20,narrowband/FDMA, OFDM, PCS/DCS, LTE/LTE-A/TD-LTE, analog cellular, CDPD,satellite systems, millimeter wave or microwave systems, acoustic, andinfrared (i.e., IrDA).

Overview

In one salient aspect, the present disclosure provides methods andapparatus for transferring protected content. In one embodiment, thecontent is delivered via a managed content distribution network (such asa cable or satellite or HFCu network having an MSO), wherein the MSOmanages the rights and restrictions of the content outside of apremises, and in a data center or headend, by providing requestedcontent to a gateway device within the premises.

The content is, in the exemplary embodiment, provided in a firstencryption format and encoded using a first codec, both of which arecompatible with the gateway device. In order to provide for a transferof the content within and outside of the premises network, the gatewayis configured to transcrypt the content into an encryption format, andtranscode using a codec, that are each compatible with a device whichrequests the content therefrom. In one implementation, the content isreceived at the gateway as MPEG-2 content encrypted using Powerkeyconditional access (CA) technology. The gateway uses its associatedCableCard to decrypt the content, and a transcoder entity to transcodethe content to e.g., MPEG-4 (or other appropriate format). The contentis then re-encrypted to DRM using a content key obtained from a DRMserver and a transcrypter of the gateway. This approach advantageouslypreserves content rights and asserts restrictions on use or distributionof content, via the user's premises gateway.

The exemplary gateway apparatus then transmits the content to arequesting client device (e.g., CPE), the CPE must use the same contentkey to decrypt the content as was used by the gateway when the contentwas transcrypted. Therefore, the gateway and devices in communicationwith the gateway (and which would presumably request content therefrom)are established to use the same DRM client.

In another embodiment, content is transferred from a DVR to otherportable devices in communication therewith to the DVR receives contentin a first format and encryption scheme, and transcodes and/ortranscrypts the content to a format and scheme with which requestingdevices are compatible. In one exemplary implementation, the requirementfor transcryption is removed by using the same DRM algorithm to protectcontent on both the DVR and the requesting devices. In one variant, theDVR and the requesting devices each use the same DRM client to request aDRM license from a DRM server.

Using the same algorithm for both client applications advantageouslyenables the MSO to control and change usage rights and restrictions atany time up through content playback, and regardless of any transfer ofthe content between devices (i.e., between the gateway and/or DVR andthe requesting devices in communication therewith).

DETAILED DESCRIPTION OF EXEMPLARY EMBODIMENTS

Exemplary embodiments of the apparatus and methods for transferringprotected content of the present disclosure are now described in detail.While these exemplary embodiments are described in the context of ahybrid fiber coax (HFC) cable architecture having a multiple systemsoperator (MSO), digital networking capability, and plurality of clientdevices/CPE, the general principles and advantages of the disclosure maybe extended to other types of networks and architectures, whetherbroadband, narrowband, wired or wireless, content or data, or otherwise.Hence, the following description is merely exemplary in nature. Forexample, the disclosure may be practiced over a fiber-to-the-home (FTTH)or fiber-to-the-curb (FTTC) system, hybrid fiber-copper (HFCu) network,or over satellite or millimeter wave-based networks having two-waycapabilities similar to today's digital cable HFC networks.

It will also be appreciated that while described generally in thecontext of a network providing service to a customer or consumer (i.e.,residential) end user domain, the present disclosure may be readilyadapted to other types of environments including, e.g.,commercial/enterprise, and government/military applications. Myriadother applications are possible.

Bearer Network Architecture

FIG. 2 illustrates a typical content distribution network configurationwith which the apparatus and methods of the present disclosure may beused. The various components of the network 207 include (i) one or moredata and application origination points 202; (ii) one or more contentsources 203, (iii) one or more application distribution servers 204;(iv) one or more VOD servers 205, and (v) consumer premises equipment(CPE) 206. The distribution server(s) 204, VOD servers 205 and CPE(s)206 are connected via a bearer (e.g., HFC) network 201. A simplearchitecture comprising one of each of the aforementioned components202, 204, 205, 206 is shown in FIG. 2 for simplicity, although it willbe recognized that comparable architectures with multiple originationpoints, distribution servers, VOD servers, and/or CPE devices (as wellas different network topologies) may be utilized consistent with thedisclosure. For example, the headend architecture of FIG. 2a (describedin greater detail below) may be used.

The data/application origination point 202 comprises any medium thatallows data and/or applications (such as a VOD-based application, gamingapplication, or “Watch TV” application) to be transferred to adistribution server 204. This can include for example a third party datasource, application vendor website, CD-ROM, external network interface,mass storage device (e.g., RAID system), etc. Such transference may beautomatic, initiated upon the occurrence of one or more specified events(such as the receipt of a request packet or ACK), performed manually, oraccomplished in any number of other modes readily recognized by those ofordinary skill.

The application distribution server 204 comprises a computer systemwhere such applications can enter the network system. Distributionservers are well known in the networking arts, and accordingly notdescribed further herein.

The VOD server 205 comprises a computer system where on-demand contentcan be received from one or more of the aforementioned data sources 202and enter the network system. These servers may generate the contentlocally, or alternatively act as a gateway or intermediary from adistant source.

The CPE 206 includes any equipment in the “customers' premises” (orother locations, whether local or remote to the servers 204, 205) thatcan be accessed by a distribution server 204 or VOD server 205.

Referring now to FIG. 2a , one exemplary embodiment of headendarchitecture useful with the present disclosure is described. As shownin FIG. 2a , the headend architecture 250 comprises typical headendcomponents and services including billing module 252, subscribermanagement system (SMS) and CPE configuration management module 254,cable-modem termination system (CMTS) and OOB system 256, as well asLAN(s) 258, 260 placing the various components in data communicationwith one another. It will be appreciated that while a bar or bus LANtopology is illustrated, any number of other arrangements as previouslyreferenced (e.g., ring, star, etc.) may be used consistent with thedisclosure. It will also be appreciated that the headend configurationdepicted in FIG. 2a is high-level, conceptual architecture and that eachMSO may have multiple headends deployed using custom architectures.

The architecture 250 of FIG. 2a further includes amultiplexer/encrypter/modulator (MEM) 262 coupled to the HFC network 201adapted to “condition” content for transmission over the network. Thedistribution servers 264 are coupled to the LAN 260, which providesaccess to the MEM 262 and network 201 via one or more file servers 270.The VOD servers 205 are coupled to the LAN 260 as well, although otherarchitectures may be employed (such as for example where the VOD serversare associated with a core switching device such as an 802.3z GigabitEthernet device). As previously described, information is carried acrossmultiple channels. Thus, the headend must be adapted to acquire theinformation for the carried channels from various sources. Typically,the channels being delivered from the headend 250 to the CPE 206(“downstream”) are multiplexed together in the headend and sent toneighborhood hubs (FIG. 2b ) via a variety of interposed networkcomponents.

Content (e.g., audio, video, data, applications, etc.) is provided ineach downstream (in-band) channel associated with the relevant servicegroup. To communicate with the headend or intermediary node (e.g., hubserver), the CPE 206 may use the out-of-band (OOB) or DOCSIS channelsand associated protocols. The OCAP 1.0, 2.0, 3.0 (and subsequent)specification provides for exemplary networking protocols bothdownstream and upstream, although the disclosure is in no way limited tothese approaches.

As shown in FIG. 2b , the network 201 of FIGS. 2 and 2 a comprises afiber/coax arrangement wherein the output of the MEM 262 of FIG. 2a istransferred to the optical domain (such as via an optical transceiver277 at the headend or further downstream). The optical domain signalsare then distributed to a fiber node 278, which further distributes thesignals over a distribution network 280 to a plurality of localservicing nodes 282. This provides an effective 1:N expansion of thenetwork at the local service end.

“Switched” Networks

FIG. 2c illustrates an exemplary “switched” network architecture alsouseful with the present disclosure. Switching architectures allowimproved efficiency of bandwidth use for ordinary digital broadcastprograms. Ideally, the subscriber will be unaware of any differencebetween programs delivered using a switched network and ordinarystreaming broadcast delivery.

FIG. 2c shows the implementation details of one exemplary embodiment ofthis broadcast switched network architecture. Specifically, the headend250 contains switched broadcast control and media path functions 290,292; these element cooperating to control and feed, respectively,downstream or edge switching devices 294 at the hub site which are usedto selectively switch broadcast streams to various service groups. A BSAserver 296 is also typically disposed at the hub site, and implementsfunctions related to switching and bandwidth conservation (inconjunction with a management entity 298 disposed at the headend). Anoptical transport ring 297 is utilized to distribute the densewave-division multiplexed (DWDM) optical signals to each hub in anefficient fashion.

Co-owned U.S. Patent Application Publication No. 2003/0056217 filed Sep.20, 2001 and entitled “TECHNIQUE FOR EFFECTIVELY PROVIDING PROGRAMMATERIAL IN A CABLE TELEVISION SYSTEM”, which is now issued as U.S. Pat.No. 8,713,623, incorporated herein by reference in its entirety,describes one exemplary broadcast switched digital architecture usefulwith the present disclosure, although it will be recognized by those ofordinary skill that other approaches and architectures may besubstituted.

In addition to “broadcast” content (e.g., video programming), thesystems of FIGS. 2a-2c can also deliver Internet data services using theInternet protocol (IP), although other protocols and transportmechanisms of the type well known in the digital communication art maybe substituted. One exemplary delivery paradigm comprises deliveringMPEG-based video content (e.g., “IPTV” or the like), with the videotransported to user PCs (or IP-based STBs) over the aforementionedDOCSIS channels comprising MPEG (or other video codec such as H.264 orAVC) over IP over MPEG. That is, the higher layer MPEG or other encodedcontent is encapsulated using an IP protocol, which then utilizes anMPEG packetization of the type well known in the art for delivery overthe RF channels. In this fashion, a parallel delivery mode to the normalbroadcast delivery exists; i.e., delivery of video content both overtraditional downstream QAMs to the tuner of the user's STB or otherreceiver device for viewing on the television, and also as packetized IPdata over the DOCSIS QAMs to the user's PC or other IP-enabled devicevia the user's cable or other modem.

Referring again to FIG. 2c , the IP packets associated with Internetservices are received by edge switch 294, and forwarded to the cablemodem termination system (CMTS) 299. The CMTS examines the packets, andforwards packets intended for the local network to the edge switch 294.Other packets are discarded or routed to another component. The edgeswitch 294 forwards the packets receive from the CMTS 299 to the QAMmodulator 289, which transmits the packets on one or more physical(QAM-modulated RF) channels to the CPEs (or CD). The IP packets aretypically transmitted on RF channels that are different than the RFchannels used for the broadcast video and audio programming, althoughthis is not a requirement. The CPE 206 are each configured to monitorthe particular assigned RE channel (such as via a port or socketID/address, or other such mechanism) for IP packets intended for thesubscriber premises/address that they serve.

Packet-Optimized Architectures

While the foregoing network architectures described herein can (and infact do) carry packetized content (e.g., IP over MPEG for high-speeddata or Internet TV, MPEG-2 packet content over QAM for MPTS, etc.),they are often not optimized for such delivery. Hence, in accordancewith another embodiment of the present disclosure, a “packet optimized”delivery network is used for carriage of the packet content (e.g., IPTVcontent) when the request issues from an MSO network (see discussion ofFIG. 2a below). FIG. 2d illustrates one exemplary implementation of sucha network, in the context of an IMS (IP Multimedia Subsystem) networkwith common control plane and service delivery platform (SDP), asdescribed in co-pending U.S. Patent Application Publication No.2011/0103374 filed on Apr. 21, 2010 and entitled “METHODS AND APPARATUSFOR PACKETIZED CONTENT DELIVERY OVER A CONTENT DELIVERY NETWORK”,incorporated herein by reference in its entirety. Such a networkprovides significant enhancements in terms of common control ofdifferent services, implementation and management of content deliverysessions according to unicast or multicast models, quality-of-service(QoS) for IP-packetized content streams, etc.; however, it isappreciated that the various features of the present disclosure are inno way limited to any of the foregoing architectures.

Protected Content Transfer Network Architectures

The following figures illustrate exemplary architectures, methods, andapparatus for providing improved systems for the transfer of content toand within a premises network. It is appreciated that althoughillustrated and discussed with respect to an HFC network, and Powerkeyor DRM encryption, the present disclosure may be applied across anynumber of networks (including e.g., satellite, Internet, cellular, etc.)and encryption or content protection schemes (such as other CA, TD,and/or DRM configurations).

Referring now to FIG. 3a , an exemplary inventive network 300configuration according to the present disclosure is illustrated. Asshown, the limitations of the prior art configurations are overcome inthat, inter alia, content is provided from a content server 302 to ahome gateway device 312, which in turn is configured to transmit contentto various client devices 206 in communication therewith. Althoughillustrated with respect to an HFC content delivery network such as thenetwork 201 of FIG. 2 herein, it is appreciated that the content server302 may communicate to the client devices 206 via any other type ofcontent delivery network, such as e.g., an internetwork, a satellitenetwork, HFCu network, etc.

Consistent with prior art methods for delivering protected content to afirst device (see e.g., FIG. 1a above), the content is provided from thecontent server 302 to the gateway 312 via the interposed deliverynetwork. In one embodiment, the content is transmitted as MPEG-2 contentusing PowerKey conditional access technology (applied at a PowerKeyencryption entity 304). However, in the illustrated inventive system,the gateway 312 is configured to process the received content, andtransmit the content to the various CPE 206 in communication therewith.The gateway 312 cannot transmit PowerKey content to CPE 206 which do nothave CableCards. Thus, in order to preserve rights and assertrestrictions for the content, the gateway 312 processes the content bytranslating it from PowerKey MPEG-2 content to DRM MPEG-4 content. Inother words, in the exemplary implementation, DRM is applied at sametime as the content is processed from MPEG-2 to MPEG-4 by the gateway312. It is appreciated, however, that in the instance that the receivingdevice utilizes MPEG-2 (or can utilize multiple formats includingMPEG-2), the translation step may be omitted.

As noted above, in certain instances it may be necessary to transcodecontent from, for example, MPEG-2 to MPEG-4. This is accomplished viaone or more prior art methods which decode the MPEG-2 content, thensubsequently re-encode the content as MPEG-4.

The application of DRM involves having many proprietary DRM “secrets”;in this case, they would need to be known by the gateway 312 performingthe content translation. In other words, in order to generate a DRMlicense, the gateway 312 would require all the secrets that are builtinto a DRM license server. However, because the gateway 312 is locatedin the user's premises, this would in essence mean that every premisesthat has the translation device (i.e., gateway 312) must also containthe proprietary DRM secrets. Such a configuration would, inter alia,significantly dilute the security of the DRM system. It is noted thatthe rights and restrictions are known at the time the content isgenerated (i.e., at the content server 302), and can be captured in bothPowerKey and DRM license prior to content translation. Hence, thepresent embodiment of the inventive architecture utilizes a DRM licensegenerated elsewhere (e.g., at a network-based DRM server 308). Thisapproach enables the DRM secrets to remain in a physically safeenvironment (i.e., the network headend and/or secure DRM server), andout of the user's premises. This also enables the translation device(i.e., gateway 312) to implement a common DRM client to retrieve thekey, which it then uses to encrypt the content. Since DRM technologiesutilize the same content key for encryption and decryption, the gateway312 requests the DRM license from the DRM server 308 using the same DRMclient as will be later used by the CPE 206 when requesting content (seediscussion below), and uses the key contained therein to re-encrypt thecontent (from PowerKey to DRM).

In order to enable the foregoing functionality, the DRM server 308 ofthe illustrated embodiment keeps a table of available content (and acontent key which corresponds to each); i.e., the content key table 310.When the gateway 312 requests the DRM license (in order to re-encryptthe content), the DRM server 310 consults an entitlements database 306to determine whether the gateway 312 is associated to an authenticateduser, and/or whether the device or user is authorized to obtain accessto the content. In addition, the rights and restrictions of the userand/or device are also determined in this embodiment via cooperation ofthe entitlements database 306, the DRM server 310 and other entities ofthe headend network (such as those associated with billing, accountmanagement, etc.; not shown). These are utilized by the DRM server 310when developing the DRM license. The rights and restrictions may includewithout limitation: (i) HDMI only, (ii) copy never, (iii) copy once,(iv) copy unlimited, (iv) number of simultaneous devices allowed, (vi)duration of use/rental, and (viii) ability to view off-line. As notedabove, the gateway 312 of the illustrated embodiment utilizes the keycontained within the DRM license to re-encrypt content received from thecontent server 302 from the exemplary PowerKey format to a DRM format.Similarly, when the user device 206 begins to play the content (whichwas transferred to it from the gateway 312), the device 206 discoversthat the content is encrypted, and requests the DRM licenses (containingthe content key) for that content directly from the DRM server 310.Based on one or more business policies set by the network operator, theDRM server 310 grants or denies the request for the content key to thatuser and/or device 206, based on entitlement information obtained fromthe entitlements database 306. An exemplary entitlements architectureand method useful with the present disclosure is set forth in co-ownedU.S. patent application Ser. No. 12/536,724 filed on Aug. 6, 2009 andentitled “SYSTEM AND METHOD FOR MANAGING ENTITLEMENTS TO DATA OVER ANETWORK”, now issued as U.S. Pat. No. 8,341,242, which is incorporatedherein by reference in its entirety. Assuming the user and/or device 206is entitled, the DRM server 310 packages the content key along with therights and restrictions in a DRM license, which is also encrypted in away that only the requesting user device 206 can access the contents ofthe DRM license.

In one embodiment, this is accomplished via utilization ofpublic/private key pair encryption schemes. It is appreciated however,that a DRM vendor may use proprietary mechanisms for ensuring that onlytrusted DRM clients can access the contents of only the DRM license towhich that DRM client is entitled.

In one exemplary embodiment, the gateway 312 is configured to run a DRMclient thereon, which is configured to request the DRM licenses from theDRM server 310 as if the gateway was the consuming device. Additionally,the gateway is further configured to run at least one computer programfor decrypting the content, and re-encrypting the content using thecontent key from the DRM license.

With respect to content stored on a DVR, current systems use proprietaryencryption algorithms at the DVR to protect content on the hard drive.Under these systems, the content must be transcrypted in order to enableDRM applications (such as e.g., the commercially available Allway® Syncn' Go DRM application, and/or the AnyPlay™ application utilized byComcast®, etc.) at the portable media devices (PMD).

Referring now to FIG. 3b , an exemplary embodiment of a networkarchitecture 350 for enabling protected transfer of content from anin-premises DVR 352 is disclosed. In the illustrated embodiment, therequirement for transcryption is removed by using the same DRM algorithmto protect content on the DVR 352 and the portable device 354. Using thesame algorithm for both applications enables the MSO to control andchange usage rights and restrictions at any time up through contentplayback, and irrespective of any transfer of the content betweendevices.

In the illustrated embodiment, content is delivered from a contentserver 302 to a network DRM encryption entity 305 for encryption, thenprovided to a DVR 352 via a network (e.g., the MSO's distributionnetwork 201) for recording. At the time of recording, the DVR 352receives, either through a request to the DRM server 308, targetedunicast, or broadcast, a DRM license for the storage of the content. TheDVR 352 uses the same DRM client as is used by the requesting devices(e.g., PMD 354) to request and process the DRM license. In oneembodiment, the DRM license only includes rights for storage andplayback on the DVR 352; alternatively additional rights may be conveyedin the DVR 352 DRM license as well (such as copy once, copy never,etc.). In the instance where the DVR 352 must re-encrypt the content (asdiscussed below) because it has utilized the same DRM client as therequesting PMD 354, the content key derived therefrom may be used forencryption.

As illustrated and in a manner similar to that discussed above withrespect to FIG. 3a , the DRM server 308 consults a content key table 310or other data structure to determine an appropriate key for delivery tothe requesting devices (DVR 352 and PMD 354). In addition, the DRMserver 308 is also configured to communicate with an entitlementsdatabase 306 (or use a comparable mechanism) to determine the rights ofthe devices and/or users to the requested content. These rights areincluded in the illustrated embodiment during generation of the DRMlicense at the DRM server 308.

In the embodiment of FIG. 3b , when a downstream client device 354requests a DVR asset DEFINE ASSET, the DVR 352 downloads the protectedasset to the client 354; if the content is in an appropriate format forthe requesting client 354. If the content is not in an appropriateformat for the requesting device 354, the DVR 352 uses its CA or DRMlicense to decrypt, transcode, then re-encrypt the DVR asset for therequesting downstream client device 354. If the content is in theappropriate format, the content is merely transmitted to the requestingdevice without processing. At the time of download or playback, thedownstream device 354 requests its own DRM license for accessing thecontent from the DRM server 308, and not from the DVR 352. In oneembodiment, the rights included in the DRM license include rights foroff-line playback.

According to the embodiment of FIG. 3b , the DVR 352 implements the DRMalgorithm to replace any proprietary encryption mechanism used in priorart DVR systems. In addition, the DVR 352 implements the DRM client toretrieve and process the DRM license in order to obtain the content keyused for decryption and encryption of the content on the hard driveusing the DRM algorithm (for subsequent transmission to client (e.g.,PMD) 354 in communication therewith).

Exemplary methods to enable the foregoing functionalities will now bediscussed in greater detail.

Methods

Referring now to FIG. 4a , one embodiment of a method 400 fortransferring protected content in a premises network, such as thatdiscussed above with respect to FIG. 3a , is illustrated. As shown, perstep 402, the premises translation device (i.e., gateway 312) requestscontent from the network as if it were an end user (e.g., contentrendering) device.

In order for the gateway 312 to encrypt the content (see discussionprovided below), it must have the correct content key for that contentelement. Note that the content key is in the present embodimentsymmetrical in nature, so the same content key is used to encrypt anddecrypt. Thus, at step 404, the gateway 312 requests the DRM licensefrom the DRM server 308. As noted above, the gateway 312 does notgenerate the content key and/or DRM license itself.

Per step 406, the DRM server 308, entitlements database 306, and contentserver 302 cooperate to determine whether the gateway 312 (and/or asubscriber associated thereto) is authorized and/or authenticated toreceive the requested content. The use, reproduction, transfer, and/orother rights of the subscriber or device with respect to the content mayalso determined. Once the authentication/authorization (and rights asapplicable) is determined, the requested content is provided to thegateway 312 from the content server 302 via the encryption entity 304(step 408), such as in PowerKey format, and the DRM server 308 generatesa DRM license for delivery to the gateway 312 as well (step 408). Thismay be accomplished via e.g., utilization of a content key table 310 orother data structure at the server 308, or a remote entity incommunication therewith.

It is further noted that the foregoing authentication/authorization maybe determined e.g., based on a subscriber ID or MAC address of arequesting device. This information may also constitute for instance aone-way cryptographic “hash” that anonymously yet uniquely identifiesthe ID or MAC address without divulging the identity of the user; seee.g., co-owned and co-pending U.S. patent application Ser. No.11/186,452 filed on Jul. 20, 2005 and entitled “METHOD AND APPARATUS FORBOUNDARY-BASED NETWORK OPERATION”, incorporated herein by reference inits entirety, for one exemplary hashing approach useful with the presentdisclosure. Alternatively, a user may be required to “log-in” to thesystem in order to have content provided thereto. A log-in requirementis especially useful in Internet or other non-managed content deliverysystems to ensure delivery to authorized users.

The gateway 312 in the illustrated exemplary HFC context tunes to theappropriate QAM for receiving the requested content, and begins decodingit. Next, at step 410, the gateway 312 transcodes the content. In oneembodiment, content is received as PowerKey encrypted and MPEG-2 encodedcontent and, while translating the MPEG-2 content into MPEG-4 forsubsequent requesting devices (e.g., CPE 206), the gateway 312 alsotranscrypts the content from PowerKey to the applicable DRM format (step412).

Rather than the gateway 312 using the content key from the previouslyobtained DRM license for decryption and play-back (as is the normalfunction of the content key at a premises device), the gateway 312 usesthe content key for translation or encryption. The gateway 312 encryptsthe piece of content using well-known DRM encryption algorithms, thenmakes it available to the requesting device in the same way a networkcontent server would. Hence, in one respect, the gateway can be thoughtof as a “local DRM-based content server” for any other premises devices.

As noted above, because the gateway 312 uses the same DRM client as therequesting device 206 to request the DRM license from the DRM server308, the content key used in translation (i.e., by the gateway 312 toencrypt the content) is the same content key is provided to the clientdevice 206 for decryption (see discussion below). This advantageouslyallows the gateway to provide a transparency or pass-throughfunctionality with respect to the DRM license/rights.

At step 414, a request for content is received from the CPE 206 at thegateway device 312 and the content is provided thereto at step 416. Whenthe requesting device 206 begins to play the content, it discovers thatthe content is encrypted, and therefore requests a DRM license for thatcontent directly from the DRM server 308, and not from the gateway 312(step 418). This allows the requesting device to implement a single DRMclient and video pipeline that operate the same way whether the contentis obtained through the gateway 312 (translation) or directly from thenetwork 201.

At step 420, the DRM server 308 determines whether the requesting client206 is authorized/authenticated to receive access to the content (andthe rights associated therewith). As discussed above, this may beaccomplished via a content key table 310 at the server 308 andcommunication of the server 308 to various network entities (includinge.g., an entitlements database 306, billing entity, account managemententity, etc.). When it is determined that the device 206 is authorizedto receive access to the content, an appropriate DRM license is providedthereto (step 422) and the CPE 106 may begin decryption and playbackaccording to the rights transmitted in the DRM license.

Another embodiment of a method 450 for the transmission of protectedcontent within a premises network, such as that discussed above withrespect to FIG. 3b , is illustrated at FIG. 4 b.

As shown, per step 452, a premises DVR 352 requests content from thecontent server 302. The DVR 352 also requests the DRM license from theDRM server 308 (at step 454). The DVR 352 utilizes the same DRM clientas is used by the PMD 354 which will request the content. In thismariner, both devices are able to access the content (via utilization ofa DRM license obtained from the DRM server 308; as will be discussedbelow).

At step 456, the DRM server 308, in response to the request for the DRMlicense, determines whether the requesting DVR 352 isauthorized/authenticated to receive access to the content, as well asthe particular rights the DVR 352 (or its user) should be afforded. TheDRM server 308, entitlements database 306, and content server 302cooperate to determine the authentication/authorization of the DVR 352(and/or a subscriber associated thereto). When it is determined that thedevice 352 is authorized/authenticated, the content is provided theretofrom the content server 302 (via the DRM encryption entity 305; step458). Additionally, the DRM server 308 generates a DRM license fordelivery to the DVR 352 as well (step 458). This may be accomplished viautilization of a content key table 310 at the server 308. Authenticationmay occur, as discussed above, based on e.g., subscriber ID, MACaddress, and/or other identifying information.

Next, per step 460, a PMD 354 requests content stored at the DVR 352.The DVR 352 determines whether the requested content is in anappropriate format to be utilized at the PMD 354, or whether processingis needed to convert the content to an appropriate format (step 462). Ifprocessing is needed, per step 464, the DVR 352 implements appropriatealgorithms to transcode the content (such as from MPEG-2 to MPEG-4). Inorder to do so, however, the DVR 352 may first decrypt the content(using the content key within the DRM license), and then re-encrypt thecontent after translation (again using the content key within the DRMlicense). In other words, the content is transcrypted (step 466). Inanother embodiment, the transcryption step (step 466) may comprisecausing the DVR 352 to, in a manner similar to the gateway 312 discussedabove with respect to FIGS. 3a and 4a , receive content in a firstencryption format (such as e.g., PowerKey) and decrypt/re-encrypt thecontent to a second format (such as e.g., DRM); see discussion abovewith respect to the aforementioned FIGS. 3a and 4 a.

If no processing of the content is needed, or once processing iscompleted, per step 468, the requested content is provided to the PMD354. The PMD 354, upon attempting to play the content, discovers that itis encrypted and thus the PMD 354 requests its own DRM license from theDRM server 308 (see step 470). The DRM server 308 then determines, atstep 472, whether the PMD 354 is authorized/authenticated to receiveaccess to the content. As discussed above, this may be accomplished viaa content key table 310 at the server 308 and communication of theserver 308 to various network entities (including e.g., an entitlementsdatabase 306, billing entity, account management entity, etc.). When itis determined that the PMD 354 is authorized to receive access to thecontent, an appropriate DRM license is provided thereto (step 474) andthe PMD 354 may begin decryption and playback according to the rightstransmitted in the DRM license.

Other Configurations

In another embodiment, the aforementioned network architectures of FIGS.3a and 3b may be used to implement a “download” paradigm for legacy ornewly developed CA, TD, and DRM software and cryptographic protectionschemes. This allows the network operator, and even the third partycontent provider by proxy, to exert additional control on viewing,reproduction, and migration of content distributed over the network. Forexample, the apparatus and methods disclosed in co-owned, U.S. patentapplication Ser. No. 11/584,208 filed on Oct. 20, 2006 and entitled“DOWNLOADABLE SECURITY AND PROTECTION METHODS AND APPARATUS”, now issuedas U.S. Pat. No. 8,520,850, which is incorporated herein by reference inits entirety, may be utilized. Specifically, the aforementioned networkarchitectures of FIGS. 3a and 3b (network 300 and network 350) areconfigured to provide downloadable software modules (e.g., images), andan associated decryption key that facilitates decryption of thedownloaded software images according to the herein described methods(see FIGS. 4a and 4b ). In contrast to the previously describedapproaches of merely encrypting the content itself (such as via a DES orAES algorithm/symmetric or asymmetric key approach), the download ofsecure software images according to the present embodiment ensuressecurity of the downloaded images and enables migration of protectedcontent to other platforms in the user or client domain so as to extendthe “trusted domain”. In other words, the architecture of the presentembodiment provides for a secure transmission of the DRM client softwareand related components, in addition to the secure delivery of the actualcontent.

The secure download approach of the present embodiment allows for readyimplementation of future security upgrades or models, such as improvedencryption algorithms and new DRM technologies. Additionally,utilization of a downloadable DRM module or image enables the presentsystem to operate with both new and legacy CAS systems, including thirdparty or retail devices (OEM devices). Devices that are connected to theoperator's network utilize a prescribed process to ensure that theclient device's download “host” has the correct software andcryptographic elements (e.g., keying) for operation on that network,regardless of whether the device comprises a lease or retailinstallation. This process advantageously enables client device hostswith inappropriate or no such software or cryptographic elements toacquire these components from the network securely.

The exemplary secure download architecture can also serve a variety ofsecurity environments and configurations ranging from the most basic(e.g., a low-end digital video service), to a high-end, multi-playenvironment with digital video, digital recording, multimedia, and dataservices. These environments can also include the ability to decryptvideo delivered by the MSO, encrypt and decrypt content stored onto orretrieved from a hard drive (e.g., for PVR devices which require DRM),and decrypt and encrypt content delivered to or being sent from the TD.

The foregoing secure download embodiment may be further used to provideenhanced media provisioning capabilities. Media provisioning describesthe process necessary to, inter alia, activate, configure, modify,and/or deactivate a CPE (e.g., downloadable conditional access (CA)system or “DCAS” host device) for operation within a content-basednetwork. For example, the apparatus and methods of the co-owned, U.S.patent application Ser. No. 11/657,828 filed on Jan. 24, 2007 andentitled “APPARATUS AND METHODS FOR PROVISIONING IN A DOWNLOAD-ENABLEDSYSTEM”, now issued as U.S. Pat.No. 8,621,540, which is incorporatedherein by reference in its entirety, may be utilized. As discussedtherein, a host device (including one or more entities associatedtherewith, such as the secure microprocessor (SM), is remotely managedby a Media Provisioning System (MPS) component of the network operator'slarger provisioning system. The MPS (and the downloadable CAinfrastructure described above) provides a secure, distributed systemfor the management of SM firmware configuration within download-capablehost devices (“DCAS hosts”).

In one exemplary embodiment, the MPS handles DCAS provisioning, andexecutes work flows to manage provisioning and configuration policywithin the operator's network. The MPS signals these policies to anauthentication agent or proxy (AP). The AP has responsibility forinteracting with the CA system's personalization server (PS), an entityuseful for the personalization of software/firmware images on individualhost devices, and is also responsible for enforcing the aforementionedprovisioning and configuration policies. In this exemplary embodiment,the MPS distributes information pertaining to the SM of each DCAS hostdevice activated within the network to a corresponding authenticationproxy (AP) within the network's conditional access infrastructure. Thus,the MPS to maintain the topological context of each SM, the SM'sidentifying information, and the SM's operationally desired softwareconfiguration.

In yet another embodiment, the aforementioned network architectures ofFIGS. 3a and 3b May be used to enable content delivery across managedand unmanaged networks. For example, the apparatus and methods disclosedin co-owned, co-pending U.S. patent application Ser. No. 12/834,801filed on Jul. 12, 2010 and entitled “APPARATUS AND METHODS FOR CONTENTMANAGEMENT AND ACCOUNT LINKING ACROSS MULTIPLE CONTENT DELIVERYNETWORKS”, now published as U.S. Patent Application Publication No.2012/0008786, which is incorporated herein by reference in its entirety,may be utilized. As discussed therein, protected content is provided tosubscribers of a managed (e.g., MSO) network via a content sourceaccessible to the subscriber via the Internet or another externalnetwork.

In an exemplary embodiment, a user accesses a third party serviceprovider (content source) website, and requests delivery of content(e.g., via on-demand type streaming, broadcast, high speed filedownload, etc.). If the particular content requested is protectedcontent or content which is only accessible to certain types ofsubscribers, the service provider and/or MSO determines whether therequesting user is permitted to access the content (such as by using theentitlements database discussed above). The process by which it isdetermined whether a user may access content includes (i) authenticatingthe user as a subscriber to the MSO, and (ii) determining whether thesubscriber's service/subscription level permits viewing of the requestedcontent (and optionally one or more use restrictions). The process isadvantageously agnostic to the underlying networks involved in both therequest and content delivery processes.

In one variant, the user is authenticated by requiring him/her toestablish a login identity and password, and/or assigning the user aGUID. The user's MAC address or IP address may also be used in thisprocess. This unique information is stored at an MSO entity, and whenthe user requests content, the user must log into the MSO; the relevantinformation is retrieved and compared to information that the user hasprovided in their login. If valid login information is entered (i.e.,the information provided matches the stored information for that userGUID), then a session is created between the MSO and user.

The aforementioned authentication at the MSO may be facilitated byvarious entities associated with the service provider. For instance, theuser may first log in to a service provider's website, such as byestablishing a login identity and password which are stored at theservice provider's site. Once logged in, the service provider mayforward requests to view content to an appropriate MSO and provide aplatform for the user to log in to the MSO site.

In another variant, the service provider and MSO accounts for aparticular user may be linked or federated. In other words, a trustrelationship is established between the service provider and MSO, whichis used to verify subscriber information. According to this embodiment,a given user will have MSO-specific information regarding its identity(such as login information for the MSO, GUID, etc.), and/or informationregarding its subscription level and other service details stored at theservice provider site. Messages received from the MSO representingpermission for the user to access content may also be stored at theservice provider site. The service provider may later reference thisinformation when subsequent requests for content are made by the userfor content, thereby providing faster and more efficient service.

In addition, the service provider is able to enforce security or rightsmanagement protection (e.g., DRM, encryption keys, etc.) on contentauthorized for delivery, by pre-positioning information enabling thisprotection (and specific to the requesting subscriber) at the serviceprovider. Alternatively, the service provider may pre-configure therequested content based on one or more configuration parametersassociated with the requesting device (e.g., codec support, DRM support,display capabilities, etc.). Information regarding a subscriber and/ordevices rights to content is obtained from the DRM server.

Gateway Device

Referring now to FIG. 5a , an exemplary gateway device 312 for use withthe systems and methods discussed in FIGS. 3a and 4a is illustrated. Asshown, the device 312 generally comprises a premises network interface512 configured to communicate with at least one CPE 206 via a respectivepremises network interface 522 thereof. The CPE 206 requests contentfrom the gateway 312 via the aforementioned communication; the gateway312 in turn requests the content from the network 502 (or receives thecontent as a part of a regularly scheduled broadcast).

In one embodiment, the gateway 312 comprises an RF front end forinterface with the HFC network 201 of FIGS. 2-2 d. The gateway 312 mayfurther comprise various components such as e.g., digital processor(s),storage device (memory), and a plurality of interfaces (e.g.,video/audio interfaces, IEEE-1394 “Firewire” or Thunderbolt™, USB,serial/parallel ports, etc.) for interface with other end-user apparatussuch as televisions, personal electronics, computers, Wi-Fi or othernetwork hubs/routers, etc., which are not illustrated herein forclarity. A tuner interface 502 of the gateway 312 is tuned to anappropriate QAM channel to receive the requested QAM content from thenetwork 201. In one embodiment, the content is encrypted using theaforementioned PowerKey encryption scheme. A cable card 504 of the typediscussed previously herein (e.g., CableCard) is used by the gateway 312to decrypt the content.

A transcoder/transcrypter 514 is also disposed at the gateway 312. Thetranscoder/transcrypter 514 receives the decrypted content from thecable card 504 and transcodes the content to an appropriate format forany devices within the premises which request the content. In oneembodiment, content is received in MPEG-2 and is transcoded to MPEG-4 bythe transcoder/transcrypter 514 within the gateway apparatus 312 fordelivery to a requesting CPE 206 capable of utilizing MPEG-4 content. Inthe instance where content is received in a format which the requestingdevice is capable of utilizing, the transcoding step may be omitted. Inaddition, the gateway uses a DRM client 510 running thereon to request,via a DOCSIS interface 506, a DRM license from a DRM system 500. Thetranscoder/transcrypter 514 uses a content key within the DRM license totranscrypt the received content from e.g., PowerKey to DRM.

The transcoded and transcrypted content is then provided to a requestingCPE 206 via the previously discussed communication between the gateway312 premises network interface 512 and the CPE 206 premises networkinterface 522.

The CPE 206, once it receives the requested content from the gateway312, begins playback of the content. However, in order to effect suchplayback, the CPE 206 requires a DRM license (to decrypt the content).Hence, the CPE 206 of the embodiment of FIG. 5a is configured to run aDRM client 520 thereon. The DRM client 520 of the CPE 206 is in theexemplary implementation the same DRM client 510 as that run on thegateway 312 (or at least has comparable capabilities). In this manner,the CPE 206 is able to decrypt content using the same content key whichwas used by the gateway 312 to encrypt the content.

It is further noted that, in one embodiment, the gateway 312 maycomprise a converged premises device, such as for example that describedin co-owned U.S. patent application Ser. No. 11/378,129 filed Mar. 16,2006, and entitled “METHODS AND APPARATUS FOR CENTRALIZED CONTENT ANDDATA DELIVERY”, now issued as U.S. Pat. No. 8,347,341, which isincorporated herein by reference in its entirety. As discussed therein,the apparatus (i.e., gateway 312) may comprise a remotely manageablepremises device that, inter alia, acts as a centralized clientnetworking platform providing gateway services such as networkmanagement as well as traditional content and high-speed data deliveryfunctions to a plurality of CPE 206 in communication therewith. Thispremises device may be used, for example, as a shared internet (e.g.,Internet) connection for all devices in the premises via a cable modemor other such interface, sharing personal and DVR content such as video,music and photos (and any associated metadata) throughout the premises,and providing both a wired and wireless network in the home. Telephonyservices utilizing e.g., embedded multimedia terminal adapter (eMTA)and/or Wi-Fi architectures may also be provided via the device; theseservices can make use of the network operator's indigenous VoIP orcomparable telephony capability if desired, thereby providing an evenmore unified service environment.

It is further appreciated that, via the gateway 312, a wired homenetwork utilizing existing coaxial cable in the premises may also becreated, using e.g., an Ethernet-to-coaxial bridge technology based onthe MoCA specification. This allows existing devices and DVRs to connectand share content with the gateway 312, and also allows the networkoperator (e.g., MSO) to control and manage the premises coaxial network.In addition, the gateway 312 may be configured to be accessible via anyremote device with internetworking (e.g., Internet) capability, therebyallowing content to be accessed by the user from outside the premises.

Still further, it is noted that the CPE 206 may comprise various othercomponents including e.g., various processing layers (e.g., DOCSIS MACor DAVIC OOB channel, MPEG, etc.) as well as media processors and otherspecialized SoC or ASIC devices. The CPE 206 may also comprise anintegrated HD decoder, thereby relieving any connected monitors or otherdevices from the requirement of having such a decoder. These additionalcomponents and functionality are well known to those of ordinary skillin the cable and embedded system fields, and accordingly not describedfurther herein.

It is also noted that, in order to perform a playback function (via themedia player 524), the CPE 206 may also provided with an OCAP-compliantapplication and Java-based middleware which, inter alia, manages theoperation of the device and applications running thereon (including theaforementioned DRM client 520 and other applications necessary forcausing transcoding, transcryption, communication, etc). Alternatively,different middlewares (e.g., MHP, ARIB, or ACAP) may be used in place ofthe OCAP middleware discussed above.

It will be recognized by those of ordinary skill that myriad differentdevice and software architectures may be used consistent with theselective enforcement functions of the present disclosure, the gateway312 and CPE 206 devices of FIG. 5a being merely exemplary.

DVR

FIG. 5b illustrates an exemplary embodiment of a DVR 352 for use withthe architectures and methods discussed in FIGS. 3b and 4b ,respectively.

As shown in the diagram of FIG. 5b , the exemplary DVR 352 generallycomprises a network interface 560 configured to receive content from anHFC network. In one embodiment, the interface comprises an RF tuner ofthe type discussed above with respect to the gateway 312 device of FIG.5a . In a further embodiment, the DVR 352 may also include a CableCardfor decryption of PowerKey encrypted content. Alternatively, thereceived content may comprise DRM encrypted content.

Content may be selected for delivery to the DVR 352 by a user thereof,or may be selected by a user of a remote device, such as a PMD 354, fordelivery to and storage at the DVR 352. In another embodiment, contentmay be provided to the DVR 352 automatically, such as based on abroadcast thereof to all devices within a service node, or via a unicast(e.g., based on an identified tendency of a user to be interested in thecontent or content similar to that which is automatically delivered).For example, the methods and apparatus disclosed in co-owned, U.S.patent application Ser. No. 12/414,576 filed on Mar. 30, 2009 andentitled “RECOMMENDATION ENGINE APPARATUS AND METHODS”, now issued asU.S. Pat. No. 9,215,423, which is incorporated herein by reference inits entirety, may be used in conjunction with the foregoing to causecontent to be automatically stored at the DVR 352. As discussed therein,content targeted to a particular user (or group of users) within acontent-based network, such as a cable television or satellite networkis identified and recommended. Specifically, a mechanism is utilized toparticularly select content to align with a user's preferences (thelatter which the viewer need not enter manually). The content providedto the user is compiled from various distinct sources, including, interalia, DVR, broadcasts, VOD systems, start over systems, etc. Inaddition, the provided mechanism may learn (and unlearn) the user'spreferences and which content they are likely to enjoy based on actionstaken with regard to previously provided (recommended) content.

The content received at the DVR 352 is processed at atranscoder/transcrypter 552. The transcoder/transcrypter 552 isconfigured to process the content received from the network 201 into aformat and encryption scheme utilized by requesting PMD 354. As notedabove, in one embodiment, the content is received in a format (e.g.,MPEG-2, MPEG-4, etc.) which is compatible with a requesting PMD 354,hence no transcoding is necessary in that instance. However, if thecontent requires transcoding, the DVR 352 will do so by first decryptingthe content using a content key retrieved from a DRM license. The DRMlicense is obtained via a request from the DRM client 554 of the DVR 352to the DRM system 500 sent over a DOCSIS interface 550. Alternatively,or in addition, the content may be received having an appropriate DRM orother encryption scheme and therefore may not necessitate transcryptionby the DVR 352.

The content is stored at a mass storage device 558 (e.g. HDD or thelike). In one embodiment, the content is stored at the storage entity558 in the format it is received and is only transcoded/transcrypted asnecessary, such as when a request for the content from a PMD 354 isreceived. Alternatively, the DVR 352 may utilize information regardingthe capabilities of PMD 354 registered thereto and preemptivelytranscode and/or transcrypt the content to one or more formats which arecompatible with one or more PMD 354 prior to storage thereof at the HDD558.

As shown, content is requested by the PMD 354 via communication of a DVRinterface 562 thereof to a PMD interface 556 of the DVR 352. Therequested content is also delivered over these interfaces. Thecommunication may comprise a wired or wireless interface including e.g.,Fire Wire (e.g., FW400, FW800, etc.), USB (e.g., USB2), Ethernet (e.g.,10/100, 10/100/1000 (Gigabit Ethernet), 10-Gig-E, etc.),Ethernet-to-coaxial bridge technology, MoCA, Wi-Fi (802.11), WiMAX(802.16), cellular (e.g., 3G, LTE/LTE-A/TD-LTE, GSM, etc.), Bluetooth,etc.

When the PMD 354 attempts to playback the content (via its media player564), it is determined that a content key is needed to decrypt thecontent. Hence, as shown, the PMD 354 further comprises a DRM client 566which is used to communicate with the DRM system 500 to obtain the DRMlicense. As discussed elsewhere herein, the various entities at the DRMsystem 500 and at the network 201 cooperate to determine appropriaterights of the user and/or requesting device to content; these are usedto generate the DRM license. It is also noted that the DRM client 566 ofthe PMD 354 is the same as (or has similar functionality to) the DRMclient 554 of the DVR 352. In this manner, the content key which is usedto encrypt the content at the DVR 352 is the same content key receivedby the PMD 354 for decryption.

The illustrated DVR 352 and/or PMD 354 may include various othercomponents which are not illustrated herein (for clarity). For example,the network interface 560 of the DVR 352 may comprise e.g., an OpenCable(OCAP)-compliant embedded system having an RF front end (including tunerand demodulator/decryptors) for interface with the HFC network 201 ofFIGS. 2-2 d. Additional digital processors, storage devices (memory),and interfaces (e.g., video/audio interfaces, Firewire or Thunderbolt™,USB, serial/parallel ports, etc.) may also be provided in the DVR 352and/or PMD 354.

Other components which may be utilized within the DVR 352 and/or PMD 354include various processing layers (e.g., DOCSIS MAC or DAVIC OOBchannel, MPEG, etc.) as well as media processors and other specializedSoC or ASIC devices. The DVR 352 and/or PMD 354 may also comprise anintegrated HD decoder.

In one variant, the client applications necessary for providing theforegoing functionalities of the DVR 352 and/or PMD 354 of FIG. 5bcomprise OCAP-compliant applications which operate via Java-basedmiddleware (including the aforementioned DRM clients, and otherapplications necessary for causing transcoding, transcryption,communication, etc.). It will be recognized by those of ordinary skillthat myriad different device and software architectures may be usedconsistent with the selective enforcement functions of the presentdisclosure, the devices of FIG. 5b being merely exemplary. For example,different middlewares (e.g., MHP, ARIB, or ACAP) may be used.

In yet another embodiment, the foregoing functionality of the gateway312 and/or DVR 342 may be implemented on a media bridging apparatus suchas that disclosed in co-owned, co-pending U.S. patent application Ser.No. 12/480,597 filed on Jun. 8, 2009 and entitled “MEDIA BRIDGEAPPARATUS AND METHODS”, now published as U.S. Patent ApplicationPublication No. 2010/0313225, and incorporated herein by reference inits entirety. As discussed therein, the device (e.g., the gateway 312and/or DVR 342) acts as a connection between a portable media device(PMD) and a user's home network. This bridging apparatus may be used,for example, to convert content stored on one client device (such ase.g., the PMD 354 or CPE 206) to a format capable of being presented ona user's set-top box or other client device. Control of the presentationis also provided by the bridging apparatus. For instance, in oneembodiment, the apparatus enables a user to access and control playbackof media from a first device via a user interface associated with asecond device. The media bridging apparatus may also enable mediacontent from a device within a premises network to be accessed viaextant networks for distribution to any STB, PC, mobile device, or otherPMD outside the premises network.

It will be recognized that while certain aspects of the disclosure aredescribed in terms of a specific sequence of steps of a method, thesedescriptions are only illustrative of the broader methods of thedisclosure, and may be modified as required by the particularapplication. Certain steps may be rendered unnecessary or optional undercertain circumstances. Additionally, certain steps or functionality maybe added to the disclosed embodiments, or the order of performance oftwo or more steps permuted. All such variations are considered to beencompassed within the disclosure herein.

While the above detailed description has shown, described, and pointedout novel features of the disclosure as applied to various embodiments,it will be understood that various omissions, substitutions, and changesin the form and details of the device or process illustrated may be madeby those skilled in the art. The foregoing description is of the bestmode presently contemplated. This description is in no way meant to belimiting, but rather should be taken as illustrative of the generalprinciples of the disclosure. The scope of the disclosure should bedetermined with reference to the claims.

What is claimed is:
 1. A premises gateway apparatus configured toprovide content to one or more client devices in communicationtherewith, said gateway apparatus comprising: at least one firstinterface configured to permit communication between said gatewayapparatus and a first network; at least one second interface configuredto communicate with said one or more client devices; a storageapparatus; and a digital processor apparatus configured to run at leastone computer program thereon, said computer program comprising aplurality of instructions which are configured to, when executed by saiddigital processor apparatus: request and receive said content and acontent key from said first network via said first interface; receive arequest originated from at least one of said one or more client devicesfor said content; in response to said received request for said content:(i) decrypt said content via said content key; (ii) transcode saidcontent from a first encoding format to a second encoding format, saidsecond encoding format being compatible with capabilities of said atleast one of said one or more client devices; (iii) re-encrypt saidcontent via said content key; and (iv) provide said content to said atleast one of said one or more client devices via said second interface;wherein said request for said content key comprises a request from adigital rights management (DRM) client running on said digital processorapparatus, and an identical DRM client is also configured to run on adigital processor apparatus of said at least one of said one or moreclient devices; and wherein said request for said content key comprisesa request for said content key from a DRM server of said first network,and said receipt of said content key comprises receipt of a content keygenerated based at least in part on a determination at said DRM serverthat said premises gateway apparatus is entitled to receive accessthereto based at least in part on communication of said DRM server withat least one database for authentication of a user associated with saidpremises gateway apparatus, said determination comprising use of saidcryptographic hash anonymously identifying said user.
 2. The gatewayapparatus of claim 1, wherein said request and receipt of said contentand a content key from said first network via said first interfacecomprises a request for said content from a first entity of said firstnetwork.
 3. The gateway apparatus of claim 2, wherein said receipt ofsaid content key comprises receipt of a DRM license.
 4. The gatewayapparatus of claim 2, wherein said first entity comprises a contentserver.
 5. The gateway apparatus of claim 1, wherein said first encodingformat comprises an Moving Pictures Experts Group (MPEG)-2 format, andsaid second encoding format comprises an MPEG-4 format.
 6. The gatewayapparatus of claim 1, wherein said received content is encryptedaccording to one or more legacy encryption techniques.
 7. The gatewayapparatus of claim 6, wherein said re-encryption of said contentcomprises encryption according to one or more digital rights management(DRM) techniques.
 8. A digital video recorder (DVR) apparatus configuredto enable synchronization of content to one or more portable mediadevices (PMDs), said DVR comprising: at least one first interfaceconfigured to communicate with one or more entities of a contentdelivery network; a second interface configured to communicate with saidone or more PMDs; a storage entity configured to store a plurality ofencrypted content received from a content server of said contentdelivery network; and a processor apparatus configured to: run at leasta digital rights management (DRM) client application thereon, said DRMclient application configured to request and receive a DRM license froma DRM server of said content delivery network, said request comprising ahash value anonymously identifying said DVR, said DRM license beingcreated based at least in part on a determination that said DVR isentitled to receive access thereto, said determination based at least inpart on communication of said DRM server with one or more entitlemententities of said content delivery network and comprising use of saidhash value; and run at least one second computer application, said atleast one second computer application comprising a plurality ofinstructions which are configured to, when executed: receive a requestfor first content from said one or more PMDs; identify said firstcontent among said plurality of encrypted content stored at said storageentity; decrypt said first content via at least information contained insaid DRM license; determine whether said identified first contentcomprises a format compatible with said one or more PMDs; when it isdetermined that said format is not compatible, transcode said firstcontent to a format compatible with said one or more PMDs; re-encryptsaid first content according to DRM standards; and provide said firstcontent and said DRM license to said one or more PMDs.
 9. The DVR ofclaim 8, wherein said plurality of encrypted content stored at saidstorage entity comprises content encrypted according to PowerKey contentaccess standards.
 10. The DVR of claim 8, wherein said at least onesecond computer application is further configured to, when it isdetermined that said format is compatible, provide said content to saidone or more PMDs in said compatible format and without transcoding saidcontent.
 11. The DVR of claim 8, wherein playback of said content atsaid one or more PMDs comprises a transmitting a request using anidentical DRM client application for said DRM license.
 12. A method ofsynchronizing content from a first premises device to at least oneportable device in communication therewith, said method comprising:storing at least first content at a storage entity of said firstpremises device, said at least first content being stored in a firstencrypted format; requesting and storing a license via a clientapplication running on said first premises device, said license receivedfrom a server in direct or indirect communication with said firstpremises device, said license based at least in part on communicationbetween the server and a database to determine that said first premisesdevice is associated with an authenticated user, said determinationbased at least in part on a hash value provided to said server thatanonymously identifies said user, said authentication configured toauthorize said first premises device to access said first content;receiving a request at said first premises device for said first contentstored at said storage entity, said request originated from said atleast one portable device; in response to said received request: (i)using at least information contained in said license to decrypt saidfirst content from said first encrypted format and re-encrypt said firstcontent to a second encrypted format; (ii) transcoding said firstcontent from a first encoding format not compatible with said portabledevice to a second encoding format compatible with said portable device;and (iii) providing said transcoded and re-encrypted first content tosaid portable device, said portable device also configured to run saidclient application configured to access said license from said server toenable said decryption of said re-encrypted first content.
 13. Themethod of claim 12, wherein said client process of said portable deviceand said client application of said first premises device compriseclient processes with common encryption/decryption capabilities.
 14. Amethod of providing content to a client device in a premises network,said premises network in data communication with a managed contentdelivery network, said method comprising: receiving said content at anintermediary entity of said premises network from a content server ofsaid managed content delivery network, said content being encryptedaccording to a first access control standard; in response to adetermination that said intermediary entity is entitled to access saidcontent, receiving a rights package from a DRM server of said managedcontent delivery network; receiving a request for said contentoriginated from said client device; authenticating a user of said clientdevice as a subscriber of said managed content delivery network;identifying a current subscription or service level of said user;determining one or more rights of said user based at least on saidcurrent subscription or service level; and performing via at least saidintermediary entity, in response to said request and based at least onsaid authenticating and said determined one or more rights: decryptionof said content via at least information received in said rightspackage; transcoding of said content from a first encoding format to asecond encoding format; re-encryption of said content according to asecond access control standard; and provision of said content and saidrights package for delivery to said client device; wherein saiddetermination comprises use of a cryptographic hash by said DRM serverand a communication with at least one database, said cryptographic hashanonymously identifying said intermediary entity.
 15. The method ofclaim 14, wherein said rights package comprises a digital rightsmanagement (DRM) license; and wherein said request is made via a DRMclient running on said intermediary entity which is configured to haveidentical protected content access functionality to a DRM client runningon said client device.
 16. The method of claim 14, wherein said secondencoding format comprises a format compatible with capabilities of bothsaid client device and at least one other client device in said premisesnetwork.
 17. The method of claim 16, wherein said first encoding formatcomprises a Moving Pictures Experts Group (MPEG)-2 format, and saidsecond encoding format comprises an MPEG-4 or H.264 format.
 18. Themethod of claim 12, wherein said first encrypted format comprisesencryption according to PowerKey content access standards.
 19. Themethod of claim 12, wherein said second encrypted format comprisesencryption according to one or more digital rights management (DRM)techniques.
 20. The method of claim 12, wherein said first encodingformat comprises an Moving Pictures Experts Group (MPEG)-2 format, andsaid second encoding format comprises an MPEG-4 format.
 21. The methodof claim 14, wherein said first access control standard comprises aPowerKey content access standard.
 22. The method of claim 14, whereinsaid first encoding format comprises a Moving Pictures Experts Group(MPEG)-2 format, and said second encoding format comprises an MPEG-4 orH.264 format.